¿Qué es la gestión de proyectos? ¿Cuáles son las etapas de la gestión de proyectos? ¿Cuáles son los tipos de gestión de proyectos?

Conjunto de tareas que se realizan para lograr un objetivo.

• Es un emprendimiento temporario
• Con un plazo determinado
• Para cumplir un objetivo o lograr un producto único.

Aspectos a tener en cuenta:

• Recursos
• Riesgos
• Cambios
• Entregables
• Alcance y calidad
• Tiempo
• Costo

Qué es gestión de proyectos

• Dirigir / Administrar un Proyecto (Project Management)
• El Proceso Mediante el cual un Proyecto es Definido, Planificado, Iniciado, Controlado y Conducido hacia su Conclusión

Aplicación de Conocimientos, Habilidades, Herramientas y Técnicas para Planificar y Administrar un Proyecto a fin de cumplir con el objetivo en forma efectiva, respecto de Costos , Tiempo y Calidad 2

4

Cuales Son las Dificultades de la Gestión de Proyectos

Qué Hacer ?

•  Procesos de Adm. De Proyectos
•  Esquema de Tareas (W.B.S.)

 Como ?

•  Técnicas de Administración y Trabajo
•  Herramientas de Soporte

 Quien ?

•  Organización del Proyecto
•  Roles y Responsabilidades

 Donde, Cuando ?

•  Planes – Guías - Estimaciones
•  Problemas
•  Oportunidades
•  Riesgos

Es el primer documento que hay que generar. Autoriza la existencia del proyecto. Confiere la autoridad para aplicar recursos de la organización a las actividades del proyecto.

No confundir plan con cronograma.

Es importante para cuidarnos

• Descripción de alto nivel: objetivos
• Quien es el líder/referente
• Los requisitos
• La lista de interesados clave
• Resumen de hitos
• Recursos financieros pre-aprobados

• Contiene los planes de toda la gestión
• Voy a gestionar el tiempo con esto. Estos recursos. Estos tiempos.
• Lo que no va a incluir . IMPORTANTE
• SE VALIDA
• Todo esto es parte del proyecto también
• Acta y plan es difícil distinguir
• Contiene los planes
• Tiempo
• Costo
• Recursos
• Calidad
• Riesgos

Alcance. WBS

Definir el alcance es muy importante.

Todo proyecto debe contar con un alcance definido y comunicado a todos los involucrados, antes del inicio del mismo.

Se define como “alcance” la descripción de todo aquello que el proyecto deberá incluir; se recomienda asimismo explicitar lo que NO se espera que incluya.

se deben considerar dos tipos de “Alcance”:

• el alcance del SISTEMA: qué se espera que el sistema “contenga”, cuáles son sus “bordes” o límites. Que está dentro y que está fuera del ámbito del sistema.
• el alcance del PROYECTO de Implementación: qué actividades contendrá el proyecto y quiénes serán responsables de su ejecución.

Aspectos que deben considerarse en la definición del Alcance

• Capacitación a usuarios finales
• Migración de datos (maestros)
• Definición y ejecución del Plan de Cut Over
• Esquema de Seguridad (nivel de acceso a las distintas funciones del sistema)
• Pruebas de Stress
• Etc.

Hago reuniones, entrevistas, leo regulaciones, etc para definir el alcance}

Afecta el costo del proyecto y los recursos que necesito.

 La estructura de desglose de recursos ( RBS ) es una lista jerárquica de los recursos relacionados con la función y tipo de recurso que se utiliza para facilitar la planificación y control del trabajo del proyecto. La estructura detallada de recursos incluye, como mínimo, los recursos de personal necesarios para la finalización con éxito de un proyecto, y preferiblemente contiene todos los recursos de los que se gastarán los fondos del proyecto, incluyendo el personal, herramientas, maquinaria, materiales, equipos y cuotas y licencias. El dinero no se considera un recurso en la RBS; sólo se incluyen aquellos recursos que va a costar dinero.

Los costos de los recursos, pueden se por hora, por costo de uso (tarifa para que me lo presten)

Asignar los recursos a las tareas. Las buenas prácticas dicen 1 tarea/dia/persona

Cuando tengo más de un recurso por tarea. Le puedo asignar porcentajes a los recursos

Hoja de recursos: veo las asignaciones (porcentajes)

En colores las sobreasignaciones

No puede haber gente sobre asignada

Informes: recursos asignadas

Seguimiento:

• La herramienta sirve para seguimiento también. Saco una foto de lo planificado: establecer la LÍNEA BASE.
• Voy completando los porcentajes y modificando la duración
• Agregar columnas; comienzo real, variación comienzo, fin real, fin de línea base
• Asi me marca los desvíos

• Al establecer una nueva línea base, debe validar con el equipo, ver si impacta los costos.
• El WBS no tiene tareas,
• Cada recurso puede tener su propio calendario con sus vacaciones
• Siempre hay cambios
• El cronograma no tiene que tener nada sobreasignado

El cronograma tiene que estar por lo menos en un lugar, el acta, o el plan. En el acta es menos detallado

(EDT): Work breakdown structure o Estructura de desglose de trabajo.

Tiene forma de organigrama. En cada nivel tengo

Puedo pensarlo por etapas? Si.

No tiene mucho detalle (no quiero mucho detalle acá)

Debe incluir todas las etapas incorporadas en la WBS, el detalle de tareas a llevar a cabo, fechas, predecesoras, recursos asignados, línea base, vista Gantt y posibilidad de incorporar los porcentajes de avance. 

Planificación:

• Volcar el WBS al cronograma.
• Divido las actividades en tareas.
• Un renglón para cada tarea.
• Tiene nombres con verbos en infinitivo
• Se asignan dependencias
• Afecta el
• Tiempo
• Recursos
• Costos
• Tengo tareas del tipo HITO
• Acá se hace la asignación de recursos
• Se establece la Línea Base
• Recordar los riesgos: cuarentena, desabastecimiento

Cronograma:

• Actividades
• Dependencias
• Duración
• Asignación de recursos
• Hitos
• Línea Base

Project

El Project sirve para planificar y seguimiento

• Le doy un nombre al proyecto
• Fecha de comienzo y fin (probablemente bien del acta o el pongo una)
• Elijo calendario (estándar,24 horas, solo noche)
• Asignación de porcentaje a los recursos
• Registrar feriados
• Trabajamos con la vista de Gantt. Hay 3 tipos de tarea Hito, resumen y subtarea
• Las actividades del BWS son mis tareas resumen, engloban otras tareas
• Hito: va con el entregable, termina en …ado, pe Infraestructura finalizada, le pongo duración “0”
• No olvidarse de agregar tiempo para la planificación

Diagrama de Gantt: representación gráfica del cronograma

Estructurar bien el proyecto:

• Relevamiento
• Contratación de recursos
• Acta

….

Pensar si vamos a usar Ágiles, cómo lo plasmamos en las herramientas

Hito:

• Va con el entregable. Es la finalización
• Tengo 1 hito por cada raviol/etapa
• Con factura/pago,
• termina en …ado, pe Infraestructura finalizada, le pongo duración “0”

Tipo de vínculo

1. Fin a comienzo (FC)

La tarea dependiente (B) no puede comenzar hasta que se complete la tarea de la que depende (A). Por ejemplo, si tiene dos tareas, "Excavar cimientos" y "Verter hormigón", la tarea "Verter hormigón" no podrá comenzar hasta que se haya completado la tarea "Excavar cimientos".

2. Comienzo a comienzo (CC)

La tarea dependiente (B) no puede comenzar hasta que comience la tarea de la que depende (A). La tarea dependiente puede comenzar en cualquier momento después de que comience la tarea de la que depende. El tipo de vínculo CC no requiere que ambas tareas comiencen al mismo tiempo. Por ejemplo, si tiene dos tareas "Verter hormigón" y "Nivelar hormigón'', la tarea "Nivelar hormigón" no podrá comenzar hasta que haya empezado la tarea "Verter hormigón"

3. Fin a fin (FF)

La tarea dependiente (B) no puede completarse hasta que se complete la tarea de la que depende (A). La tarea dependiente puede completarse en cualquier momento después de que se haya completado la tarea de la que depende. El tipo de vínculo FF no requiere que ambas tareas se completen al mismo tiempo. Por ejemplo, si tiene dos tareas, "agregar cableado" e "inspeccionar electricidad", la tarea "inspeccionar electricidad" no puede completarse hasta que se complete la tarea "agregar cableado".

4. Comienzo a fin (CF)

La tarea dependiente (B) no puede completarse hasta que comience la tarea de la que depende (A). La tarea dependiente puede completarse en cualquier momento después de que comience la tarea de la que depende. El tipo de vínculo CF no requiere que la tarea dependiente se complete al mismo tiempo que comienza la tarea de la que depende. Por ejemplo, la trusa del techo para el proyecto de construcción se ha creado fuera del sitio. Dos de las tareas del proyecto son "entrega de truss" y "ensamble tejado". La tarea "montar techo" no se puede completar hasta que comience la tarea "entrega de truss"

Project. Escala temporal:

Puedo tener niveles (semanas, mese, días , semestre, años)

Las tareas resumen suman las duraciones de las tareas que la componen

Hay técnicas para estimar. Usualmente debería estimar el que lo va a hacer. El equipo debe estimar

CRONOGRAMA: artefacto vivo, herramienta dinámica

Tareas, ejemplo:

• Definir alcance
• Identificar riesgos y medidas de mitigación
• Armar el BWS
• Costos: confeccionar presupuesto
• Comunicaciones

El método del camino crítico

Las técnicas pioneras de la moderna gestión de proyectos son el PERT (Program Evaluation and Review Technique, 1958) y el CPM (Critical Path Method, 1957). El método PERT fue desarrollado por la marina de los Estados Unidos para gestionar el Proyecto Polaris, en el que la marina había contratado a más de 250 empresas que a su vez habían subcontratado al menos a otras 9000 empresas. Se trataba de un proyecto de gran envergadura, no sólo desde el punto de vista técnico, sino también a nivel organizativo. Casi de forma paralela e independiente, la empresa Du Pont desarrolla el método CPM para gestionar el mantenimiento de sus plantas de producción. Ambos métodos son casi idénticos en esencia, aunque tenían algunos aspectos que los diferenciaba. PERT  y CPM se conocen hoy día como Método del Camino Crítico. En términos generales, su utilidad reside en:

    1. Exigir el establecimiento de las relaciones de precedencia.     2. Exigir la estimación de duración para cada actividad.     3. Ayudar a realizar una mejor utilización de los recursos de personal y materiales al identificar los cuellos de botella del proyecto.     4. Determinar las actividades críticas.     5. Facilitar la programación y hacer el seguimiento y control del proyecto.

Gestión de costos. Presupuesto

Objetivos. Alcance, tiempo costos

1. Necesitamos una estimación financiera al principio
2. Necesitamos una planificación
3. Seguimiento y/o ajuste

Podemos usar una plantilla, en Excel

¿Quién soy? En calidad de qué? ¿Cuál es mi rol? Gerente de sistemas? PM?

¿A quien está dirigido? Al cliente? ¿Al área de finanzas? En qué lenguaje habla?

Tengo que tener la WBS (y para la WBS tengo que tener al alcance y haber hablado con el patrocinador)

Hay que ver qué precios? ¿Qué nos conviene? ¿En la nube? On premises ?

Ojo con las licencias de SW, lo divido, ¿qué corre en los clientes? Y qué en los server?

Licencias de BD, SO

Algunos son anuales, debería proyectar a 3 años

Podría usar distintas hojas de cálculo

Hay dos tipos de estimaciones.

• Analógica
• Paramétrica
• Ascendente (la preparo con mucho detalle)

Por 3 valores probable, optimista, pesimista

Si el proyecto es a 2 años, tengo que agregar supuestos

Aclarar lo que es moneda extranjera, tipo de cambio

Que incluye, que no incluye

Armar cashflow (meses/columnas)

Hay que ponerle línea base y seguimiento

Agregar el VAN,TIR

Vas a aumentar las ventas en xx%, vas a ahorrar xxx$$$

Supuestos: tasa mensual de ….

O inflación no superior a…

Se supone contrato directo con los proveedores

Gestión de la calidad

define las directrices a seguir en materia de política de calidad de una empresa, con competencias de planificación, recursos o procesos.

Un sistema de gestión de calidad recoge una serie de normas y estándares que deben cumplirse. La norma ISO 9001 se ocupa de establecer los requisitos para certificar que una organización cuenta con un sistema de calidad conforme a los estándares que se contemplan.

Con estas normas se establecen todos los procedimientos que se deben llevar a cabo durante la actividad productiva de la empresa, definiendo la estructura organizativa, los procedimientos que se van a realizar o los recursos que se deben emplear.

El objetivo final es cumplir con los estándares de calidad fijados para asegurar que el resultado final va a ser el mejor para nuestros clientes, a la vez que se simplifican todos los procesos durante la producción.

Para asegurar la calidad del proyecto hay que seguir estándares y definir:

• Objetivos
• Roles y responsabilidad
• Mediciones Tengo que medir
• Y qué pasa si no alcanzó los estándares

Entregables

• Actividades de control de calidad
• Herramientas
• Procedimientos. Si no alcanza la NO CONFORMIDAD, acciones correctivas, mejoras continuas
• Costos de conformidad: prevención y evaluación (evitar fallas)
• Costos de NO CONFORMIDAD: fallas internas (retrabajo o deshecho) y fallas externas (garantías o perder clientes)
• Costos de prevención:
• Capacitación
• Doc de procesos
• tiempo
• Costos de evaluación
• Pruebas
• Inspecciones

Gestión del Riesgo

La realización de un informe de gestión de riesgos sigue una estructura que comprende la descripción de la empresa y sus objetivos, la identificación y evaluación de riesgos, los controles, el riesgo residual, la estrategia y toma de decisiones, los planes de acción, la supervisión o auditoría externa y, finalmente, unas conclusiones y recomendaciones.

1. Descripción de la empresa. Misión, visión, objetivos estratégicos y organigrama.
2. Objetivos. Políticas y procedimientos, formación normativa legal, apetito al riesgo, servicios externalizados y riesgo aceptado.
3. Identificación de riesgos. Ficha/cuestionarios/listado riesgos fraude.
4. Evaluación de riesgos. Cualitativo, cuantitativo y riesgo inherente.
5. Controles. Preventivo, detectivo y correctivo.
6. Riesgo residual. Matriz de riesgos.
7. Estrategia/toma de decisiones. Cumplir normativa, costes de implementación, mapa de riesgos y análisis costes/beneficios.
8. Planes de acción. FODA/DAFO.
9. Supervisión/Auditoría externa.
10. Conclusiones y recomendaciones.

En la descripción de la empresa se observa qué tipo de organización es; la actividad que realiza; su ámbito de actuación, nacional o internacional. El conocimiento de los objetivos estratégicos de la empresa permitirá saber cuáles son sus límites y a dónde quiere llegar.

En la identificación de los riesgos específicos de la empresa se tienen en cuenta riesgos producidos en organizaciones de características similares, considerando riesgos legales, financieros, operacionales y reputacionales.

Una vez identificados los riesgos se procede a su evaluación tanto cuantitativa como cualitativa. A partir de ella se obtiene el riesgo inherente.

Los controles a aplicar en función de las normativas, compliance, plan de continuidad de negocio. Aquí se consideran los controles financieros, planes de crisis, emergencias,… para la obtención del riesgo residual y saber cuánto de controlada está la empresa.

La toma de decisiones se realiza por parte de la alta dirección y el consejo de administración, máximos responsables del proceso de gestión de riesgos en las empresas. Ante la toma de decisiones, se establecen los planes de acción, para la reducción de la probabilidad o del impacto, fundamentalmente con el análisis coste-beneficio.

En los últimos puntos del informe de gestión de riesgos se contempla la supervisión y auditoría externa. Muchas empresas están obligadas a la implementación de la gestión de riesgos y, por tanto, tienen supervisores que revisan todo este proceso. El resumen final obtenido con el desarrollo de esa gestión es plasmado en unas conclusiones y recomendaciones.

Consideraciones

● Obtención de información

● Integración, participación

● Ambiente de la organización, proyecto

● Mejora continua (dinamismo, adaptación)

Elementos

• Riesgo inherente: independiente de los hechos
• Riesgo residual: después del plan de acción
• Matriz de riesgos: documento donde están todos los riesgos
• Apetito de riesgo; Cantidad y Tipo de Riesgo que una organización está dispuesta a aceptar
• Tolerancia : es la desviación respecto a este nivel. (apetito)
• Capacidad: máximo de riesgo que una organización puede soportar 
• Riesgo de control: riesgo de algo no sea controlado

Proceso de riesgo

1. Identificar: armó la planilla con ID, tipo(por etapas, o áreas), descripción, efecto 1 y efecto 2(por ejemplo costos y reputación)
2. Estimar: calcular la probabilidad de ocurrencia (justificar, puede ser alto/bajo/medio/%). Justificación. Impacto (justificar: cuanta plata me cuesta o cualitativa). Ponderación (combinaciones de 1-3). Nivel de riesgo(alto/medio/bajo). Riesgo residual
3. Tratamiento: puede ser plano actual. Plan preventivo, sector involucrado(responsable). Costo adicional del plan. Plan reactivo. Sector responsable del reactivo. Costo adicional del reactivo
4. Monitoreo: métricas/indicadores. Se debe ajustar la probabilidad al nivel del riesgo

Matriz de riesgo

• Métricas
• Se debe ajustar la probabilidad al nivel de riesgo
• Pregunta:
• ¿Qué podría salir mal?
• Identificar: matriz
• Plan: mitigar o prevenir
• Aclarar, detalles, clasificar
• Ir desagregando
• Agregar probabilidad de ocurrencia, ranking, etc.
• Identificar factor :técnicos, no técnicos, legales

Estrategias

• Evitar: hago todo para que no ocurra(100%)
• Reducir: es lo recomendable(anular, mitigar)
• Transferir: que el riesgo lo asuma otro (contratar un seguro)
• Aceptar: no hago nada (lo asumo, 0%)

Factores a considerar

➔ Política de gestión de riesgos

➔ Roles y responsabilidades

➔ Diccionario de riesgos (importante: escala) para que no haya confusión

➔ Obtención de evidencia

Como crear una Efectiva Matriz de Riesgos en tan solo 3 Pasos

Paso 1:

Lógicamente el primer paso será identificar el máximo posible número de riesgos para nuestro proyecto. Para ello nos deberemos reunir con los stakeholders que nos puedan aportar la mayor información y analizar el posible origen de los riesgos.

Para obtener el mayor número posible de riesgos y no dejarnos ninguno olvidado por el camino, podemos ayudarnos de una RBS (Risk Breakdown Structure), la RBS nos ayudará en nuestras sesiones de brainstorming con los interesados del proyecto a buscar riesgos en todas las áreas posibles.

Paso 2:

Después de la identificación de los riesgos, el siguiente paso sería hacer un análisis cualitativo y a ser posible también cuantitativo de los mismos para poder clasificarlos de mayor a menor importancia en nuestra Matriz de Riesgos.

Paso 3

Una vez analizada la probabilidad y el impacto de los riesgos del proyecto, siguiendo los pasos 1 y 2, procederemos a cumplimentar la Matriz de Riesgos (podéis descargar una plantilla de la misma aquí).

En esta matriz indicaríamos por un lado el riesgo, y por otro su probabilidad e impacto, el resultado de multiplicar PxI (Probabilidad x Impacto) será la clasificación global del riesgo, podemos usar un código de colores para los riesgos en nuestra matriz como el siguiente: verde (riesgo bajo), amarillo (riesgo medio), rojo (riesgo alto).

Por último y no por ello menos importante, recordad que la Matriz de Riesgo es un documento «vivo», es decir deberemos actualizarla constantemente para que sea un reflejo de la realidad y nos sea una herramienta útil.

Para ello deberemos revisar la Matriz de Riesgos en todas las reuniones de reporte de estado del proyecto, y comentar los riesgos que nos han impactado, los que no, clasificarlos de nuevo, modificar la probabilidad y el impacto si estos han variado, etc.

Gestion de los interesados

Stakeholders

Internos: sponsor, gerente de RRHH, OMO

Externos : cliente, proveedores, accionistas, organización

Sponsor: ayuda al PM a destrabar

Guardo el grado de influencia, expectativas. Grado de interés. Partidario/Neutral/reticente. Nombre. Rol.datos de contacto, etc

Tips: para la gestión

Objetivos claro

Relaciones humanas

Trabajar en equipo

Cuidar:

• Las personas
• Comunicación
• Metodología
• Adaptabilidad
• Gestión del cambio

Habilidades:

Empatía, Intuición, escuchar.

Ser parte, Compromiso, humildad, aprendizaje, adaptabilidad, negociación, paciencia

Gestión de las operaciones de IT

Que es la gestión de la operación

• Tareas y procesos que optimizan para lograr la eficiencia
• Asegurar la sustentabilidad
• Aumentar los márgenes de ganancia

¿Qué es distinto en IT?

• Se enfoca en el desarrollo de las Relaciones HH
• Penetración de la tecnología
• Introducción de nuevos riesgos

Riesgos operacionales

• Dependencias de activos de IT
• Personal
• Cambios introducidos

ISO 38500

La ISO/IEC 38500 es un estándar internacional para el Gobierno de TI. Provee un marco para gobernar las TI al interior de las organizaciones, brindando un conjunto de principios que son de interés de la alta dirección en los procesos de evaluación, dirección y seguimiento al uso de las tecnologías de la información (TI).

El estándar es mantenido de manera conjunta por la Organización Internacional de Estandarización y la Comisión Electrotécnica Internacional.

Dentro de los beneficios de un buen gobierno de TI estaría la conformidad de la organización con:

• los estándares de seguridad.
• Legislación de privacidad.
• legislación sobre el spam.
• Legislación sobre prácticas comerciales.
• derechos de propiedad intelectual, incluyendo acuerdos de licencia de software.
• regulación medioambiental.
• normativa de seguridad y salud laboral.
• Legislación sobre accesibilidad.
• estándares de responsabilidad social.

La información es el activo más importante

COBIT 5

COBIT 5 es la última edición del framework mundialmente aceptado, el cual proporciona una visión empresarial del Gobierno de TI que tiene a la tecnología y a la información como protagonistas en la creación de valor para las empresas.

COBIT 5 ayuda a empresas de todos los tamaños a:

• Optimizar los servicios, el coste de las TI y la tecnología
• Apoyar el cumplimiento de las leyes, reglamentos, acuerdos contractuales y las políticas
• Gestión de nuevas tecnologías de información

Cobit 5 está basado en cinco principios:

1. Satisfacer las necesidades de los interesados.
2. Cubrir la empresa de extremo a extremo.
3. Aplicar un solo marco integrado.
4. Habilitar un enfoque holístico.
5. Separar gobierno de administración

CATALIZADORES COBIT 5

Los catalizadores son factores que, individual y colectivamente, influyen sobre si algo funcionará – en este caso, el gobierno y la gestión de la empresa TI.

El marco de referencia COBIT 5 describe siete categorías de catalizadores:

• Principios, políticas y marcos de referencia son el vehículo para traducir el comportamiento deseado en guías prácticas para la gestión del día a día.

• Los procesos describen un conjunto organizado de prácticas y actividades para alcanzar ciertos objetivos y producir un conjunto de resultados que soportan las metas generales relacionadas con TI.

• Las estructuras organizativas son las entidades de toma de decisiones clave en una organización.

• La Cultura, ética y comportamiento de los individuos y de la empresa son muy a menudo subestimados como factor de éxito en las actividades de gobierno y gestión.

• La información impregna toda la organización e incluye toda la información producida y utilizada por la empresa. La información es necesaria para mantener la organización funcionando y bien gobernada, pero a nivel operativo, la información es muy a menudo el producto clave de la empresa en sí misma.

• Los servicios, infraestructuras y aplicaciones incluyen la infraestructura, tecnología y aplicaciones que proporcionan a la empresa, servicios y tecnologías de procesamiento de la información.

• Las personas, habilidades y competencias están relacionadas con las personas y son necesarias para poder completar de manera satisfactoria todas las actividades y para la correcta toma de decisiones y de acciones correctivas.

ITIL

La Biblioteca de Infraestructura de Tecnologías de Información (o ITIL, por sus siglas en inglés) es un conjunto de conceptos y buenas prácticas usadas para la gestión de servicios de tecnologías de la información, el desarrollo de tecnologías de la información y las operaciones relacionadas con la misma en general. Marco de gestión basado en el ciclo de vida del servicio.

DevOps

DevOps es una práctica de ingeniería de software que tiene como objetivo unificar el desarrollo de software y la operación del software

DevOps es un enfoque que promueve la colaboración entre líneas de negocio, desarrollo y operaciones de TI. Es una funcionalidad empresarial que habilita la entrega continua, el despliegue continuo y la supervisión continua de aplicaciones. Reduce el tiempo necesario para tratar el feedback de los clientes. El desarrollo y las operaciones, e incluso las pruebas, antes se organizaban en silos. DevOps las reúne para mejorar la agilidad.

• Desarrolladores, testers y especialistas en operaciones trabajan en colaboración mediante las herramientas compartidas de DevOps.
• Facilita la entrega continua de software gracias a la realización de pruebas en colaboración y la supervisión continua de los entornos de desarrollo, integración y transferencia.
• Corrige desalineaciones de personas y objetivos creando vínculos más cercanos entre desarrolladores y operaciones.
• Las herramientas facilitan la gestión de releases, el suministro de la infraestructura, la orquestación, la supervisión, la inclusión en contenedores, la virtualización y la automatización.
• Incorpora el feedback de los clientes en el proceso de desarrollo para acelerar la respuesta a errores y mejoras.

Principios:

✓ Desarrollar y comprobar contra sistemas similares a los de producción

✓ Implementar mediante procesos fiables y repetibles

✓ Monitorizar y validar la calidad operativa

✓ Amplificar los bucles de feedback

Técnicas

Conclusiones

Gobierno y gestión de IT:

• Administrar relación negocio-objetivos-estrategias en TI
• Maximizar potencial, controlando riesgos
• Calidad
• Alineación estratégica
• Cliente como protagonista